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Dear Sir: 

We, Keith E. Goldstein and Stuart Blank, hereby declare and state as follows: 



1. This Declaration is submitted as evidence that the subject matter claimed in the above- 
identified application was invented prior to June 28, 2002. 



2. We are the persons named as inventors in the above-identified application. 



3. Prior to June 28, 2002, we conceived and reduced to practice in the United States the 
invention of claims 1-33 and 37-56 in the above-identified application. 



4. Exhibit A attached hereto is a copy of a draft application prepared for and provided to 
us by Robert E. Hunt of Wolf, Greenfield & Sacks, PC, for review prior to June 28, 2002 in 
preparation for filing U.S. provisional application 60/405,243, filed August 22, 2002. Exhibit A 
also includes a copy of an email letter with which the draft application was forwarded. The date 
that the email was sent was redacted prior to its copying. 
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5. The draft application included in Exhibit A accurately describes the invention we 
made prior to June 28, 2002 and provides support for currently pending claims in the above- 
identified application. For example, claims 1-9 of the draft application in Exhibit A substantially 
correspond to claims 1-6 and 18-20 of the above-identified application. 

6. Prior to June 28, 2002, we supervised and participated in the actual reduction to 
practice of a system that was used to verify the accuracy of a group of gift cards. (The system was 
also used to verify the accuracy of several other groups of transaction cards, but only one such 
group is discussed herein.) The group included several thousand cards and was logically partitioned 
into multiple, discrete sets (or sleeves) of cards. The system included a reader that read an identifier 
(a printed bar code or magstripe representing an identifier) from each gift card in a set of cards 
carried by a conveyor. (In some cases, two identifiers were formed on each card, e.g., a bar code 
and magstripe) and both identifiers could be read and stored by the system.) A sensor was also used 
to detect the presence of individual cards on the conveyor, e.g., to indicate that a card is positioned 
for reading by the reader and trigger the reader to read the card's identifier. The identifier read from 
the cards uniquely identified each of the cards from other cards in the group and was usable in 
associating a transaction involving the card (such as a purchase of goods) with an issuee of the card 
(such as a future purchaser of the gift card). The system included a computer system arranged to 
compare the identifiers obtained from the reader to a stored list of identifiers for the gift cards. The 
stored list represented a set of identifiers that were intended to be included on each of the gift cards 
in the group. The computer system was arranged to provide an approval report (such as a printed, 
tamper-evident label to be affixed to a container in which the cards were located) only if the 
identifiers read from the cards matched corresponding identifiers in the stored list. The computer 
system was configured to determine whether sets of the gift cards included missing, duplicate or 
otherwise unexpected cards, and could determine whether the cards in a set were arranged in a 
specified sequence. The computer system was arranged to form a temporary file of identifiers read 
from a set of cards, insert that temporary file into a database, and compare the identifiers in the 
temporary file to identifiers in the stored list. The identifier comparison operation was initiated by 
an operator manually reading an identifier (i.e., reading the identifier using a handheld bar code 
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reader) from the first and last cards in a set while the cards were held in a container, i.e., a sleeve. 
That is, after the identifiers were read from all cards in a set, the cards were assembled into a 
container and the comparison operation initiated. The system was capable of prompting the 
operator to re-read an identifier from one or more cards in the sleeve that may have been earlier 
misread. The system could use the manually read identifier to complete its analysis, e.g., to 
determine if the card was properly located in the set. The system was enabled to store various types 
of information about the cards, such as a total number of cards in each set (or sleeve), a sleeve, box 
and/or pallet in/on which each card is located, a read or packaging status for each card, and other 
information. 

7. Exhibit B includes an internal sales training document that was prepared and used 
prior to June 28, 2002 to educate sales staff regarding the operation and capabilities of the system 
described above in Item 6. Dates included in this document were redacted prior to its copying. 

8. The document in Exhibit B provides evidence that the system generally described in 
Item 6 above was reduced to practice and used for processing of transaction cards, such as gift 
cards. This document provides details of the ScanGuard system that was implemented by which bar 
code information printed on gift cards could be read by custom design scanners and its accuracy 
verified against a customer's master file using proprietary software. The verification process 
involved checking for duplicates, missing cards and precise sequencing and counting of cards. 
When the verification process is complete, cards could be packaged into a sleeve, and a label 
affixed to the sleeve, carton and skid detailing the contents therein. The label would only be printed 
if the contents of the sleeve, carton and skid were accurately documented. 

9. Exhibit C includes a one page report created prior to June 28, 2002 by the system 
generally described in Item 6 above. Dates included in this document were redacted prior to its 
copying. 

10. The document in Exhibit C provides evidence that the system generally described in 
Item 6 was reduced to practice and used for processing of transaction cards. This document 
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provides a report of analysis for a sleeve of 500 cards, and includes information such as the number 
of expected cards, the number of cards scanned, and the number of cards misread, removed, 
replaced or missing from the sleeve. 

11. We hereby declare that all statements made herein of our own knowledge are true, 
and that all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine and/or imprisonment under Section 1001 of Title 18 of the United States Code, 
and that such willful false statements may jeopardize the validity of the application or any patent 
issuing therefrom. 



Date: 



Date: 




Stuart Blank 
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Subject: Application 
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Keith, A draft of the application is attached. I would have liked more time to work on it, but have stopped to keep 
the costs down. I'll send the password and drawings by fax. 

Bob 
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RANSACTION CARD FABRICATION CONTROL SYSTEM AND METHOD 

FIELD OF THE INVENTION 
This invention relates to controlling transaction card fabrication. 

BACKGROUND OF THE INVENTION 
Transaction cards, such as credit cards, identification cards, purchaser loyalty cards, 
prepaid telephone cards, and so on, are commonly manufactured using high speed encoding 
and printing apparatus. For example, many types of transaction cards must be personalized, 
i.e., encoded, printed, or otherwise processed so that each card in a given set of cards is 
uniquely identified from other cards in the set. For example, transaction cards in a loyalty 
card program may be encoded and/or printed to carry a unique identifier such as an alpha 
numeric string encoded in a magnetic stripe on the card or printed as a barcode on the card. 
This unique identifier allows each card in a group of cards to be uniquely identified with a 
particular issuee so that future transactions made with the card can later be associated with 
the issuee. 



SUMMARY OF THE INVENTION 
The inventors have appreciated that in some cases it may be desirable to provide 
large groups of transaction cards, i.e., groups having 1,000, 10,000, 100,000 or more cards, 
so there are no duplicate or missing cards in the group of cards and/or in a contiguous 
manner such that the cards are arranged in a specific sequence. For example, transaction 
cards may be arranged in numerical sequence according to an identifier encoded or printed 
on the cards, e.g., so card no. 1 precedes card no. 2, which precedes card no. 3, and so on. 
Providing the cards in a specific sequence may allow for easier inventory control of the 
cards and/or ensuring that previously unissued cards are still under the control of the issuer. 
Further, providing groups of cards so that there are no duplicate or missing cards in the 
group can avoid problems such as two different persons being issued cards with a same 
identifier (thereby causing confusion regarding to whom transactions made with a card 
bearing the identifier should be associated) in the case of duplicate cards, or causing 
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inconvenience or wasted time in determining whether a card has been lost or stolen in the 
case of missing cards from the group. 

In one aspect of the invention, a comprehensive transaction card fabrication control 
system can ensure that a group of cards is produced and/or packaged in multiple card sets, or 
sleeves. A comprehensive audit trail may be generated that indicates precisely which cards 
are included in which sleeves, allowing accurate tracking of cards, assuring that there are no 
duplicate or missing cards in the group, and/or assuring that cards have been assembled from 
the appropriate component parts. Thus, a relatively large group of transaction cards, e.g., 
1000, 10,000 or more cards, may be arranged in multiple sets, or sleeves, of smaller 
numbers of cards, e.g., 100, 200, 500 or more cards. Reports generated by the control 
system may allow an operator to determine exactly which cards are located in each sleeve 
and which component parts or other features each card may include. The system may also 
ensure that cards in each sleeve are arranged in a particular sequence. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Illustrative embodiments in accordance with the invention are described below with 
reference to the follow drawings in which like numerals reference like elements, and 
wherein: 

FIG. 1 is a schematic block diagram of a first embodiment in accordance with the 
invention; 

FIG. 2 is a schematic block diagram of a second embodiment in accordance with the 
invention; and 

FIG. 3 shows an example database table for use in accordance with the invention. 

DETAILED DESCRIPTION 
Fig. 1 shows a schematic block diagram of an illustrative embodiment in accordance 
with the invention. In this illustrative embodiment, a transaction card fabrication control 
system 100 includes a card manufacturing apparatus 2 that generates a group of transaction 
cards, i.e., a plurality of transaction cards which are all related to each other. For example, 
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cards in a group may be related to a particular job or customer, such as loyalty cards for a 
particular grocery store chain. The card manufacturing apparatus 2 may use any suitable 
process or combination of processes to generate the cards. Cards may be processed by the 
manufacturing apparatus 2 so that each card includes an identifier that is unique to the card 
and distinguishes the card from all others in the group. The identifier may take any suitable 
form, such as an alpha numeric string encoded in a magnetic stripe on the cards, a barcode 
printed on each card, biometric information associated with the card, information stored in 
an electronic memory on the card, etc. 

Since the total number of cards typically produced in a group is quite large (10,000, 
100,000 or more cards), the control system 100 may break the group down into card sets, or 
sleeves, of a more manageable size. Individual cards may be associated with a particular 
sleeve based on the card's identifier and the card/sleeve association information stored so 
that a detailed audit trail for cards in the group is maintained. Such an audit trail may allow 
the system 100 to ensure that there are no duplicate or missing cards in the group, and allow 
an operator to determine exactly which cards are located in which sleeve. This information 
may be useful, for example, if one or more sleeves are lost, stolen or damaged so 
replacement cards can be made, or particular cards inactivated. 

Association of cards with individual sleeves may be made in different ways. For 
example, as cards for a particular sleeve are output by the manufacturing apparatus 2, the 
cards in the sleeve may be processed by a verification system 3 that reads information (an 
identifier) from the cards and uses the identifier to ensure that cards in the sleeve are 
properly associated with the sleeve. In one illustrative embodiment, one or more identifiers 
read from each card by the verification system 3 may be compared to a stored list of 
identifiers. If a matching identifier is located in the stored list, a database or other store of 
information may be updated to indicate that a card with the identifier has been read and is 
associated with a particular sleeve, i.e., the sleeve being processed by the verification system 
3 when the identifier was read. As a result, each particular card read by the verification 
system 3 may be associated with a particular sleeve for later reference. The system may also 
ensure that all identifiers in the stored list are properly associated with one and only one card 
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by checking each identifier read from each card in the group against the stored list. If two 
cards are read having the same identifier, the system 100 may indicate the problem to an 
operator. Similarly, the system 100 may indicate if there are missing cards from the group, 
or from particular sleeves. 

The stored list of expected identifiers may be generated in any suitable way, such as 
before any cards in the group are produced by the manufacturing apparatus 2. The stored 
list of identifiers may then be used by the manufacturing apparatus 2 to form identifiers on 
the cards. That is, identifiers from the stored list may be supplied to the manufacturing 
apparatus 2 and used to form identifiers on cards. Alternately, the stored list may be 
generated based on information from the manufacturing apparatus 2 indicating which 
identifiers have been formed on cards, e.g., as an identifier is formed on a card, the 
manufacturing apparatus 2 may indicate that a card with the identifier has been made and the 
identifier added to the stored list. 

In the embodiment described above, sleeves may be generated "on the fly" so that 
particular cards and their identifiers are associated with a particular sleeve at or after the 
time cards are read by the verification system 3. In an alternate embodiment, called a "zero- 
gap" procedure, a detailed list of identifiers and the sleeves to which the identifiers are 
associated may be generated before cards are processed by the verification system 3. In this 
procedure, when cards for a particular sleeve are processed, identifiers read from the cards 
are compared to identifiers in the list and a check is also made that the card is associated 
with the proper sleeve. For example, if the stored list indicates that the identifier "ABC1" is 
associated with sleeve "01", but the card having the identifier "ABC1" is read by the 
verification system 3 during processing of sleeve "02", an error may be indicated to prompt 
correction by an operator. A check may also be made to ensure that there are no duplicate 
cards (cards having a same identifier) are present in a sleeve or between two different 
sleeves, or that there are no missing cards in a sleeve. 

Further, comparison of identifiers read from cards for a sleeve may involve a check 
that the cards are arranged in a sequence that matches a sequence defined in the stored list. 
For example, the stored list may include a list of identifiers and the order in which cards 
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bearing the identifiers are to be present in a sleeve. Identifiers read from cards in a sleeve 
may be compared in the order they were read to the identifiers in the list to ensure that the 
cards are properly ordered. 

Confirmation that the cards are in a proper sequence in a sleeve or otherwise 
properly associated with the sleeve may be provided by a report generated by the system 
100, e.g., a label having an adhesive backing that is printed to indicate the sleeve number, 
the range of cards included in the sleeve, the customer, a job description, and any other 
suitable information. The label may be adhered to a boxed or otherwise packaged sleeve of 
cards to indicate that the sleeve is complete and ready for shipment, storage or other use. 

As discussed above, the card manufacturing apparatus 2 may include any suitable 
devices to perform desired card manufacturing functions. In the illustrative embodiment 
shown in Fig. 1, the system 100 includes a card feeder 21 that supplies cards onto a card 
transport 27, such as a conveyor belt. Although the cards may be arranged in any suitable 
way, in this illustrative embodiment, the cards include a magnetic strip and an area on which 
a barcode may be printed. A unique identifier, such as an alpha-numeric string, along with 
other optional information may be encoded on the magnetic strip of the cards by an encoder 
22 as the cards are moved by the card transport 27. Details regarding the operation of the 
encoder 22 and other portions of the manufacturing apparatus 2 are not provided as these 
operations are well understood by those of skill in the art. A magnetic strip reader 23 may 
read the encoded magnetic strip on each card, e.g., to ensure that the strip has been properly 
encoded. A printer 24, such as an ink jet printer, a laser marking apparatus, embossing 
device, or other suitable device for marking the cards, may print a barcode or other unique 
identifier on the cards. Information printed by the printer 24 may match information 
encoded on the magnetic strip. For example, a unique alpha numeric identifier may be both 
encoded in the magnetic strip and printed in barcode form on the cards. A camera 25 may 
image the information marked on the cards by the printer 24 to ensure that the cards have 
been properly marked. Improperly processed cards, such as cards that are improperly 
encoded, printed or otherwise processed, may be removed from the card transport 27 by a 
card diverter 26, e.g., a gate or other device that physically removes cards from the transport 



27. Cards removed from the transport 27 may be cycled back to be reprocessed, or 
discarded. 

The controller 1, which may or may not include the terminal 33, communicates with 
the card manufacturing apparatus 2 and/or the card verification system 3 to control operation 
of the system 100 and/or provide information to an operator. The controller 1 may be, or 
include, one or more general purpose computers including any suitable software and/or other 
components to perform the desired input/output or other functions. For example, the 
terminal 33 may provide local control for the manufacturing apparatus 2 and/or the 
verification system 3 under the overall, system-level control of the controller 1 . The 
terminal 33 may include user input devices, such as a keyboard, mouse, barcode scanner, 
touch screen or other devices to provide input to the terminal 33 or the controller 1. A 
printer 34, video monitor or other display may provide output information to the user, 
including printed hard copy reports, processing status information, or other information. 

Although the verification system 3 may include any suitable device(s) to read 
identifiers from cards and perform other desired functions, in this illustrative embodiment, 
the verification system 3 includes a card sensor 31 and a card reader 32 that receive cards on 
the card transport 27 downstream from the manufacturing apparatus 2. The card sensor 3 1 
may operate to sense cards as they pass on the transport 27, e.g., to trigger reading of an 
identifier on a card by the card reader 32. The card sensor 3 1 may also indicate the presence 
of an unreadable or unread card if the card reader 32 fails to read an identifier from a card or 
if the card does not include a readable identifier. Such information may be valuable since 
improperly formed cards may be removed, or remade or reprocessed by the manufacturing 
apparatus 2. 

In the Fig. 1 embodiment, the card manufacturing apparatus 2 may be controlled to 
make sleeves of cards in a contiguous fashion so the verification system 3 can verify the 
integrity of the sleeve as it is produced by the manufacturing apparatus 2. For example, an 
operator may instruct the controller 1 (via the terminal 33) that a particular sleeve of cards 
has been output by the manufacturing apparatus 2 and should begin processing by the 
verification system 3. (Alternately, the controller 1 may itself increment or otherwise 
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initiate processing of a sleeve by the verification system 3 without input from an operator. 
For example, the controller 1 may automatically begin processing a first sleeve when the 
first card in a group is output by the manufacturing apparatus 2 and automatically initiate 
processing of subsequent sleeves every time after a certain number of cards in the sleeves, 
100, 200, or more cards, are output by the manufacturing apparatus 2.) Once the cards are 
output by the manufacturing apparatus 2, the card sensor 31 can sense the presence of 
individual cards and the card reader 32 can read a unique identifier on each of the cards, 
such as an alpha numeric string encoded in a magnetic strip, printed as a barcode on the 
card, or other information, to identify each card in the sleeve. The information provided by 
the card sensor 3 1 and card reader 32 then may be used by the controller 1 to determine if all 
cards in the set are present and/or are organized in a particular sequence by comparing the 
read identifiers to a stored list of expected identifiers. If the cards sensed by the card sensor 
3 1 and card reader 32 are present and/or organized in a desired sequence for the set, a report 
may be generated that indicates the set is complete and ready for packaging. The report may 
be an electronic document that is stored at the controller 1, a label that is printed by the 
printer 34, or any other suitable information set that confirms a set of cards has been 
confirmed to be in a proper order and/or contains all cards in the set. Complete card sets 
then may be packaged, e.g., placed in a box and closed for shipment. Accordingly, once a 
set of cards has been packaged, the card fabricator can be sure that all cards in the set are 
contained within the box and/or organized in a desired sequence. 

Fig. 2 shows a second illustrative embodiment in accordance with the invention. In 
this illustrative embodiment, a transaction card fabrication control system 100 includes two 
or more verification stations 3 that communicate with a central controller 1. Unlike the Fig. 
1 embodiment, in this embodiment previously fabricated cards may be provided to each 
verification station 3 at some time after the cards are output by a manufacturing apparatus 2. 
Thus, the system 100 in Fig. 2 may allow the integrity of card sets to be verified where the 
cards are manufactured off-site, or at some time in the past by a manufacturing apparatus 
that is physically distant from the verification systems 3. The Fig. 2 embodiment also does 
not require the verification system 3 to process cards at a same rate that the manufacturing 
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apparatus 2 produces cards. For example, a manufacturing apparatus 2 may output cards at 
a rate of 10,000 cards/hour or higher. By having verification systems 3 separated from the 
manufacturing apparatus 2, the verification systems 3 may operate at a lower processing 
rate. In addition, having multiple verification stations 3 operating under a central controller 
1 allows the information produced by each verification station 3 to be integrated together, if 
necessary, when multiple verification stations 3 are verifying the integrity of card sets for a 
same group of cards. Alternately, the verification stations 3 may verify the integrity of card 
sets for different card groups while having the verification information compiled at a central 
location. 

Although the verification stations 3 may be arranged in any suitable way, in this 
illustrative embodiment, each verification station 3 includes a card feeder 21 into which 
fabricated cards are provided. The card feeder 21 then may feed the cards onto a card 
transport 27 which moves the cards relative to a card sensor 31 and card readers 32. 
Although two card readers 32 are shown in this illustrative embodiment, e.g., to read one or 
more identifiers from each card, each verification station may include any suitable number 
or type of devices to verify the unique identity of each card. The card sensors 3 1 may 
include a photoelectric eye or other sensor that detects the physical presence of the cards and 
may then trigger reading by the card readers 32. In addition to triggering card reading, the 
card sensor 3 1 can indicate the presence of a card when the card reader 32 failed to read an 
identifier or other information from a card, as discussed above. This occurrence may 
indicate that an improperly read or unread card is present in the set and prompt an operator 
to correct the situation. For example, the operator may physically inspect the unread card to 
determine if the card has been improperly processed during manufacture, e.g., a barcode has 
not been printed on the card, or if the card readers 32 simply failed to read a properly 
manufactured card. 

As mentioned above, a group of cards including a total of 1000, 10,000 or more 
cards may be logically organized into multiple sets of cards, or sleeves, before manufacture. 
Information representing the card organization into sets may be stored in the controller in a 
list, such as in database or any other suitable form. Fig. 3 shows an example table that may 
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be used to manufacture and/or verify the integrity of card sets. In this illustrative example, 
the table includes a Card No, column in which an arbitrary card number may be indicated. 
This card number may be used as a shorthand or otherwise easier way to reference particular 
cards in the group or in selected sleeves since card identifiers may be relatively long alpha 
numeric strings with apparently random sequencing. In this example, card numbers start at 
1 and increment up to a total number of cards in the group, but other card numbering or 
other reference schemes may be used. 

This illustrative database table also includes an Identifier column including the 
identifier for each card number. The identifier may be any suitable alpha numeric string or 
other information that uniquely identifies each card from other cards in the group. This 
unique identity of each card allows the identifier to be used in associating particular 
transactions with an issuee of the card. For example, if the transaction card is a customer 
loyalty card, purchases made using the card may be associated with the person or other 
issuee of the card. 

The table in Fig. 3 also includes a Sleeve column for indicating the associated sleeve 
for each card. In this example, card numbers 1-10 are associated with sleeve "0001," card 
numbers 1 1-20 are associated with sleeve "0002," and so on. Again, any suitable numbering 
or other identification of sleeves may be used. The example table also includes a Card 
Read Status column for indicating whether a card having the identifier has been read by a 
verification station 3. That is, information in this column may indicate whether the 
identifier read from a card matches a corresponding identifier in the Fig. 3 table. For 
example, cards may be read by the verification system 3 one set, or sleeve, at a time and the 
identifiers read from cards within the sleeve compared to identifiers associated with the 
sleeve from the table. For example, cards in sleeve "0001" may be read and the identifiers 
obtained from the cards compared to the identifiers in the Fig. 3 table for all cards in sleeve 
"0001 ." If a card read in the sleeve has an identifier that matches one in the table, a "1" 
value or any other suitable value may be entered into the table to indicate that a card having 
the corresponding identifier has been read for the sleeve. In this example, card nos. 1-8 read 
for sleeve "0001" have identifiers matching identifiers in the Fig. 3 table as indicated by the 
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"1" value in the Card Read Status column. However, card 9 which has a "0" value in the 
Card Read Status column, indicates no card has been read to have an identifier matching 
that in the table. Card 10, which has a "2" value in the Card Read Status column, may 
have actually had two cards read in the sleeve having the identifier associated with card no. 
10. This problem may have occurred because of a reading or data transmission error, or 
because there were two cards in sleeve "0001" having the identifier corresponding to that for 
card no. 10 and no card having the identifier for card 9. Since an error has been detected in 
reading cards for sleeve "0001," a "No" indication is entered in the Sleeve Complete 
column of the table. Thus, sleeve "0001" is not ready for packaging or shipment to a 
customer. Of course, if a card is read as having an identifier that is associated with the 
wrong sleeve, an appropriate indication, such as a "3" value in the Card Read Status 
column, may be recorded in the table. If desired, an additional column may be added to the 
table to indicate which sleeve(s) the erroneous card/identifier pair was read in so the card 
can be retrieved and placed in the appropriate sleeve. For example, if the verification 
system 3 is currently reading sleeve "0002" and reads a card having an identifier that is 
associated with sleeve "0001," the table may be updated to indicate the improper read in the 
Card Read Status column and the sleeve "0002" where the erroneous card is located 
indicated in the table as well. The table also may include any other suitable information, 
such as operator or verification station information as shown. Other information, including 
whether the sleeve has been packaged, shipped, or otherwise processed, or other information 
regarding a manufacturing history or other audit trail for the cards. 

In some embodiments, the identifiers read from cards in each sleeve may be 
compared in the sequence that they were read to a sequence of identifiers in a stored list. 
This type of comparison can ensure that cards are arranged in a desired sequence that 
matches the identifier sequence in the stored list. Such a comparison may be performed in 
real time as each identifier in the sleeve is read from actual cards, or a temporary file may be 
built that stores the identifiers read from cards in the order in which the identifiers were read 
for cards in the sleeve. If a temporary file is built, the temporary file may be compared to a 
stored list of identifiers for the sleeve, such as the table shown in Fig. 3. For example, a 



temporary file of identifiers read from cards in sleeve "0001" may be generated and 
compared, in the order that the identifiers were read, to the identifiers in the Fig. 3 table in 
the order they are listed. Such a comparison can assure that not only all cards with 
appropriate identifiers are included in a particular sleeve, but that the cards are arranged in a 
particular sequence in the sleeve. 

Of course, the identifiers read from cards for each sleeve need not be compared in 
the order in which they were read to a stored list of identifiers. For example, the system 100 
may compare identifiers read for cards in a sleeve without regard to the order in which they 
were read to ensure that all cards in the sleeve have an identifier that matches an identifier 
associated with the sleeve. Such a comparison also may ensure that no two cards have a 
same identifier in each sleeve and within the entire group of cards. Similarly, card 
identifiers need not be logically organized into sleeves before cards are read by the 
verification system 3. For example, the Fig. 3 table may be initially created with the Sleeve 
column empty. As cards are read in particular sleeves and their identifiers matched to those 
in the table, the sleeve in which the card and identifier is read may be indicated in the Sleeve 
column. This approach allows sleeves to be created "on the fly" by the system 100 while 
ensuring there are no duplicate or missing cards from a group of cards. 

If any error is detected in reading cards in a sleeve, an operator may be directed to 
the problem card or cards, e.g., by information provided at the terminal 33 and rectify the 
problem. Once the problem has been corrected, the sleeve again may be read in its entirety 
to ensure that the sleeve is complete and the problem has been corrected. Once a sleeve is 
complete, the system 100 may generate a report that indicates one or more sleeves have been 
read as complete. For example, the printer 34 may print a label or other printed report that is 
associated with a corresponding complete sleeve of cards. This report may indicate the 
sleeve, card numbers or card identifiers included in the sleeve, or other information and may 
be required to release the sleeve for shipment to a customer. The report also may be stored 
electronically for future reference if necessary. 

Initiation of sleeve reading may be made automatically by the verification system 3, 
e.g., after reading a specific number of cards in a sleeve as counted by the card sensor 3 1 , 
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the verification system 3 may increment or otherwise logically go to a next sleeve for 
processing. Alternately, initiation of sleeve reading may be manually begun by a user 
inputting a sleeve number into the terminal 33 and instructing the system 3 to begin card 
reading. That is, an operator may load a sleeve of cards into a card feeder 21, enter the 
sleeve number into the terminal 33, and initiate reading of the cards. Before beginning, the 
system 100 may check to see if the sleeve has been previously read, and prevent reading or 
require supervisor intervention before proceeding. Such security can help prevent errors in 
sleeve entry into the terminal 33 and in appropriate rereading of sleeves. Once card reading 
is complete, the system may automatically begin comparing the identifiers read from cards 
to a stored list of identifiers. Alternately, a user may manually initiate the identifier 
comparison for the sleeve integrity check. For example, after cards for a sleeve have been 
read, an operator may gather the cards and place them in a tray or box. The operator may 
read an identifier for the first and last cards in the sleeve, e.g., using a terminal's hand-held 
bar code reader that reads a barcode identifier from the cards, and manually instruct the 
system to begin the comparison for the sleeve that begins and ends with the identifiers 
manually read by the bar code reader. (Alternately, the user may manually enter the sleeve 
number to initiate the integrity check.) After the processing is complete, the system 100 
may indicate whether the sleeve is complete or not, i.e., whether there is a missing or 
duplicate card in the sleeve, the cards are out of sequence, etc., and the operator may take 
the appropriate action to rectify any errors or package a complete sleeve. 

It should be understood that the basic concepts behind ensuring that cards are 
properly fabricated discussed above may extend to areas other than personalization of the 
cards, i.e., providing each card with a unique identifier. For example, cards typically are 
assembled from two or more components, such as separately printed front and back panels 
that are secured together to form the card. Clearly, a card must have the proper front and 
back panels associated with each other if the card is to be properly made. The various card 
portions that are assembled together may each include some sort of identifier that may be 
machine read before or during the time that the portions are assembled together and 
compared to stored information to ensure that the various portions should be combined 
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together to form the card. For example, a card front portion may include a barcode number 
and a back portion may include another barcode number. Before or at the time the front and 
back portions are secured together to form one or more cards, the barcode numbers may be 
read and compared to stored information to ensure that the appropriate front and back panels 
are being properly assembled to form the card(s). Such information may be included in a 
table such as that shown in Fig. 3 or in any other suitable form. It also should be noted that 
the database may be formed in any suitable way, such as a relational database. As a result, a 
comprehensive audit trail may be created for all stages of card fabrication, ensuring that 
cards are properly made at each processing step. 

As mentioned above, transaction cards used with the invention may be formed in any 
suitable way using any suitable processes in accordance with the invention. For example, 
the manufacturing apparatus 2 may form holographic information on the cards, encode or 
otherwise provide information to an electronic chip or other device associated with each 
card (such as in the case with electronic cash cards), may mark the cards with biometric 
information (such as fingerprint, iris, or other information associated with an authorized user 
of the card), or otherwise process the cards. In addition, the transaction cards need not 
necessarily have the commonly-known credit card shape (also know as a CR80 shape), but 
instead may have any suitable shape and any suitable number of interconnected components. 
For example, each card may include a CR80 portion with attached keytags, coupon tags, or 
other portions. Portions of the card may be perforated, scored or otherwise formed so that 
the various portions may be separated from each other. Transaction cards may be made of 
plastic or paper sheets of material or any other suitable material. 

While the invention has been described in conjunction with specific embodiments 
thereof, it is evident that many alternatives, modifications and variations will be apparent to 
those skilled in the art. Accordingly, preferred embodiments of the invention as set forth 
herein are intended to be illustrative, not limiting. Various changes may be made without 
departing from the spirit and scope of the invention. 
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CLAIMS 

1 . A transaction card fabrication control system comprising: 

a card reader that reads an identifier from transaction cards that uniquely identifies 
each transaction cards from all other transaction cards in a group of transaction cards and 
facilitates an association of a transaction involving the transaction card with an isuee; 

a card transport that moves transaction cards relative to the card reader; 

a card presence sensor that detects the presence of transaction cards moved by the 
card transport; and 

a controller that compares identifiers read from a set of transaction cards by the card 
reader to a stored list of identifiers for the set of transaction cards and generates an approval 
report only if all identifiers read from the set of transaction cards match all corresponding 
identifiers in the stored list. 

2. The system of claim 1 , wherein the controller generates an approval report only if the 
identifiers read from the set of transactions cards match all corresponding identifiers in the 
stored list and if the identifiers were read from the set of transaction cards in a sequence that 
matches a sequence in the stored list. 

3. The system of claim 1, wherein the controller builds a temporary file of identifiers 
read from the set of cards and compares the identifiers to the stored list after all transaction 
cards in the set have been read by the card reader. 

4. The system of claim 1, wherein the approval report includes a printed form that 
indicates the set of transaction cards includes all cards with identifiers matching a stored list 
of identifiers for the set. 

5. The system of claim 1, wherein the controller stores a plurality of lists of identifiers 
each corresponding to an associated set of transaction cards and compares identifiers read 
from sets of transaction cards to a corresponding stored list of identifiers to determine if 
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transaction cards in the set have identifiers that match corresponding identifiers in the stored 
list. 

6. The system of claim 1 , wherein the card presence sensor causes the card reader to 
read transaction cards. 

7. A method for controlling transaction card fabrication, comprising: 

providing fabricated cards having at least one identifier formed on each card that 
uniquely identifies the card from others in a plurality of sets of transaction cards; 
reading identifiers from the plurality of sets of cards; 

comparing identifiers read from transaction cards in each set to a stored list of 
identifiers associated with the set; 

determining if the identifiers read from transaction cards in each set match 
corresponding identifiers in the stored list associated with the set; 

generating a report that indicates a set is complete if identifiers read from the set 
match a corresponding identifier in the associated stored list; and 

generating a report that indicates a set is incomplete if identifiers read from the set do 
not all match a corresponding identifier in the associated stored list. 

8. The method of claim 7, wherein the step of comparing identifiers comprises 
comparing the identifiers in a sequence in which the identifiers were read from the 
transaction cards in the set to a sequence of identifiers in the stored list. 

9. The method of claim 7, wherein the step of reading identifiers from the plurality of 
sets of cards comprises building a temporary file of identifiers read from each set of cards, 
and the step of comparing identifiers comprises comparing identifiers in the temporary file 
to the stored list associated with each set after all transaction cards in the set have been read. 



ScanGuard™ Technology 
By Arthur Blank & Co. 

In , Arthur Blank & Co. introduced ScanGuard Technology to their manufacturing 

process. ScanGuard is a high speed beam scanner based technology that has been implemented into 
the various stages of card production and personalization to insure accuracy in graphic design, card 
counts, data integrity, labeling, packaging and documentation of numerical integrity for the gift card 
customer. 

ScanGuard Technology as it is applied to the card numbering process can be best described in this 
step by step methodology: 

1 . The card's mag stripe is encoded and/or a bar code is applied to the card through a high-speed ink 
jet process on Arthur Blank & Co.'s Atlantic Zieser (AZ) inkjet machines. 

2. The barcode is read by a series of custom design scanners built into the production line that 
verifies through proprietary software that the data file imaged onto the card matches that which is 
contained within the customer's master file. 

3. The barcode is read to insure that the card has not been duplicated in the inkjet process; it is read 
to insure that the cards are being inkjetted in exact sequence as to the customer's master file. 
Lastly the software is checking to insure that there are no missing numbers within the sequence. 

4. The AZ's have an auto remake process that will automatically reject a duplicated card and remake 
it in line with no human intervention. Because of the ScanGuard Technology it will also remake a 
card in sequential order should it read that there is a "missing" card. 

5. Once the cards have gone through this ScanGuard process it will go to a secondary line where the 
cards will again be scanned to insure no duplications, missing numbers or out of sequence issues. 
This secondary line will also double count the cards to insure that the count is exact. 

6. Once this process has been completed and the sleeve of cards has proven to be in perfect order 
with no duplicates, no missing numbers, in sequential order and with an exact count, a label will 
then be printed to go onto the sleeve identifying the contents of that sleeve. The sleeve is banded at 
that point and sent on for packaging into a master carton where again our scanners are used to 
document the sleeves going into the master carton with the exact label describing the contents 
within. The same scanning process occurs with the label that is generated for the skid. 

7. Under no circumstances through out this process can the label be printed unless the sleeve, master 
carton and skid are perfectly numbered and documented. The operators and their supervisors can 
not override this process. 

8. With ScanGuard Technology Arthur Blank & Co. can give the gift card customer a complete 
return vendor file and is able to audit our process down to the second that the card was produced 
and what sleeve, master carton and skid where the card resides. 

With ScanGuard Technology Arthur Blank & Co. has developed a fail-safe process that will allow us 
to produce to a very high quality level on all of the cards we personalize no matter the run size. We 
have removed the human intervention factor that can often times create havoc in a gift card program. 
For further information please contact Arthur Blank. 

ScanGuard Technology is a registered trademark of Arthur Blank & Co., Inc. 
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